Medical imaging study retrieval system

ABSTRACT

A programmed computer system receives an imaging study of the patient including metadata associated with the study. The metadata are analyzed to determine an anatomic region represented by the study. Additional imaging studies for the same patient are requested and the metadata associated with the additional studies are analyzed to determine relevant studies for the same or adjacent anatomic regions. Once the relevant prior studies have been identified, the computer requests the images associated with the identified prior imaging studies including the associated reports for review by a physician or other medical personnel.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority to and the benefit of U.S.patent application Ser. No. 61/729,263, filed on Nov. 21, 2012 andtitled MEDICAL IMAGING STUDY RETRIEVAL SYSTEM.

FIELD OF THE TECHNOLOGY

The technology disclosed herein relates to medical information systems.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an interconnected medical information system in whichprior relevant imaging studies of a patient are determined and retrievedin accordance with an embodiment of the disclosed technology;

FIG. 2 illustrates a communication link set up between a router computera hospital picture archive computer system (PACS) and a hospitalinformation system (HIS) in accordance with an embodiment of thedisclosed technology;

FIG. 3 illustrates how an imaging study is forwarded from a picturearchive computer system at a hospital or other medical center to therouter in accordance with an embodiment of the disclosed technology;

FIG. 4 illustrates how the router requests metadata for additional priorimaging studies based on a patient identifier retrieved from thereceived imaging study in accordance with an embodiment of the disclosedtechnology;

FIG. 5 illustrates how the router requests prior relevant imagingstudies from one or more picture archive computer systems based on ananalysis of received metadata in accordance with an embodiment of thedisclosed technology; and

FIG. 6 illustrates how the router requests reports associated with thedetermined relevant patient imaging studies from one or more radiologyinformation systems (RIS)/hospital information systems (HIS) inaccordance with an embodiment of the disclosed technology.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In order to accurately assess and diagnose a patient's condition,physicians often want to compare a patient's current examination resultswith examination results that were performed in the past. This isparticularly true in radiology, whereby images of a patient's anatomycan be compared to prior images to determine growth of a tumor, healingof an injury or any other number of physiological changes that thephysician considers in making their diagnosis and treatmentrecommendations.

One difficulty in reviewing prior imaging studies of a patient is thatsuch studies may be stored across numerous computer systems associatedwith different hospitals, clinics, medical centers or the like. Inaddition, even if all of a patient's prior studies were located on thesame computer system, there is currently no commonly accepted conventionfor indicating what portion of a patient's anatomy is represented by astudy.

Most medical imaging studies are stored and transmitted electronicallyaccording to a DICOM (Digital Imaging and Communication in Medicine)standard. Currently the standard does not have an accepted protocol forspecifying what portion of a patient's anatomy is represented in thestudy. While an imaging study typically has metadata associated with it,such metadata often does not specify the particular anatomy imaged. Forexample, a study of the patient's head may have metadata that includesthe word “head” but may also include metadata that includes the names ofadjacent body parts such as “neck” or “shoulder,” or can includenegative metadata keywords such as the words “not head.”, or acronymssuch as “HD” In the past, a physician, nurse or trained medicalpersonnel would have to visually inspect each of the prior studies inorder to retrieve all the prior imaging studies that are relevant to thecurrent imaging study. Such a review can occupy a significant amount oftime and thereby increases the overall cost of healthcare for thepatient or insurance provider.

To address these problems and others, the technology disclosed hereinrelates to a computer system that is programmed to automaticallyretrieve relevant prior imaging studies from one or more computersystems on which such studies are stored. The computer systems may beconnected on a single communication network or may be located ondifferent communication networks.

In one embodiment, a computer system, such as a router computer, isprogrammed to analyze metadata associated with a received imaging study.The metadata is analyzed to determine a likely anatomic regionrepresented in the imaging study based on a heuristic analysis of themetadata tags or entries. After the metadata has been analyzed, animaging study is classified by its represented anatomic region. Therouter system then analyzes the metadata of the received imaging studyfor patient information such a patient identifier, code or even lastname, first name etc. The router then sends a request to one or morePACS at the same or different medical facilities for metadata associatedwith prior imaging studies associated with the same patient.

The router analyzes the received metadata to classify the prior imagingstudies according to the particular anatomic region depicted. Studies ofthe same anatomic region or adjacent regions are identified as beingrelevant to the current study. The router then requests that the imagesof the relevant imaging studies identified be sent to the router. Inaddition, the router requests that any reports associated with theidentified relevant studies are also sent. Once the prior studies andassociated reports are received, they can be stored and/or combined foreasy access by a physician so that the physician can determine how acurrent imaging study relates to previous relevant imaging studies ofthe same or adjacent anatomic regions.

FIG. 1 illustrates a system for retrieving prior imaging studies of apatient in accordance with one embodiment of the disclosed technology.The system 100 includes a computer system 102 that is in communicationwith one or more medical information systems that may be located athospitals or other medical facilities H1-HN. The computer system 102 maybe located on the same communication network as the medical informationsystems of a single hospital (i.e. behind a firewall or othercommunication barrier). Alternatively, the computer 102 may be connectedto the medical information systems via a wide area communication linksuch as the internet 110. In the example shown, a patient 120 visits thehospital H1 with a condition such as a head injury and is examined usingany number of imaging modalities such as X-rays, CT scans, MRIs,ultrasound etc. In the example shown, the patient may receive a CT scanof their head from an imaging system operated by the hospital H1. Theimaging study can then be forwarded through a communicationlink/internet 110 to the computer system 102 through conventionalcomputer communication protocols. The communication protocols typicallyinclude appropriate security measures as required by the DICOM standardfor handling a patient's confidential medical information. The retrievedimaging study is then available for a physician to view and analyze ontheir own computer system 140. The physician's computer system 140 maybe directly connected to the computer 102 or may be remotely connectedthrough the internet 110 or other computer communications network.

In order for the physician to diagnose a patient's condition, thephysician may want to view prior imaging studies of the patient'sanatomy or adjacent anatomy. These prior imaging studies may be locatedin one or more remotely located hospitals, clinics medical centers,doctor's office or the like.

As indicated above, current DICOM standards do not follow a conventionalnaming practice that identifies the particular anatomic region containedin an imagining study. Therefore, the computer system 102 analyzesmetadata associated with the received imaging study to determine whatanatomical region is represented. The computer system 102 then requestsmetadata associated with other prior imaging studies that were obtainedfor the same patient. The computer system 102 then analyzes the metadatathat are associated with those studies to determine one or more relevantprior studies. In one embodiment, the studies that are determined to berelevant are those of the same or an adjacent anatomic region as theanatomic region depicted in the received or current imaging study. Oncethe prior relevant imaging studies have been identified, the computersystem requests that the images associated with the identified studiesbe sent to the computer system 102 from the one or more hospitals H1-HNalong with the reports that accompany those studies.

FIGS. 2-5 illustrate steps performed by the computer system 102 toclassify a received imaging study to determine the anatomic regionrepresented as well as to request prior relevant imaging studies.

As shown in FIG. 2, the computer system 102, such a router computer maybe in communication with other radiology information system (RIS)computers 160 or picture archive computer systems (PACS) 170 for storingthe received imaging studies and reports. The computer system 102 isalso connected via a computer communication link, such as the internet110, to computer systems associated with one or more hospitals or othermedical facilities. Such computer systems typically include a hospitalPACS 200 and hospital radiology information systems(RIS)/hospitalinformation systems(HIS) 204. Together these computer systems storeimages and associated reports produced in response to studies performedwith medical imaging equipment such as ultrasound machines 210, CTscanners 212, X-ray machines 214, magnetic resonance imaging (MRI)machines 216 or other similar systems.

In the embodiment shown in FIG. 3, once an imaging study of a patient iscomplete, a technician (not shown) stores the study from one of theimaging machines to the hospital picture archive computer system 202.When the study is complete, it is sent by conventional means to thecomputer system 102. The study is typically sent via a secure privatenetwork point-to-point communications or VPN. Upon receipt of thecurrent study by the computer system 102, the study may be forwarded forstorage on the PACS 170.

In the embodiment shown in FIG. 4, the computer system 102 analyzesmetadata associated with the received study to determine a patientidentifier, patient name or other code that uniquely identifies aparticular patient. The computer system 102 then sends requests for themetadata associated with other prior imaging studies that are associatedwith the same patient. The metadata for prior imaging studies arereturned from the hospital PACS system(s) 202 to the computer system 102and can be stored on the RIS computer system 160.

In the embodiment shown in FIG. 5, the computer system 102 analyzes thereceived metadata to determine those studies that are relevant to thecurrent imaging study. As will be explained in further detail below, theassociated metadata is analyzed with one or more heuristics orprogrammed rules to determine which studies represent the same oradjacent anatomic regions as that represented in the current imagingstudy

In the embodiment shown, the computer system 102 communicates with asingle hospital PACS system 202. However we appreciated that thecomputer system may query multiple PACS or other medical informationsystems associated with other hospitals, clinics, doctor's offices orother locations where relevant prior imaging studies may be stored.Typically, the requests associated or sent to the other medical centersinclude an identifier of the patient such as their last name, middleinitial, first name, date of birth, and sex as determined from theanalysis of the metadata of the current imaging study.

In addition to requesting the images for the prior imaging studies ofthe same or adjacent anatomic regions that are determined by thecomputer system 102, a physician may also request images for specificprior imaging studies based on information in the patient's file orother information. A request for the images associated with theidentified relevant and requested prior imaging studies is then sent tothe hospital PACS 202 (and other medical information systems ifappropriate). The images associated with these requested studies arethen returned to the computer system 102 where they may be stored on thecomputer system 170.

The computer system 102 also requests any reports associated with theidentified or requested prior imaging studies from the hospital RIS/HISsystem(s). The received reports may be stored in the RIS computer 160.Once the appropriate imaging studies and associated reports have beenreceived, they can be analyzed by the physician to diagnose the patient.

As indicated above, one embodiment of the disclosed technology analyzesthe metadata associated with the current and prior imaging studies todetermine likely anatomic areas represented by the studies. In oneembodiment, the following heuristics are used to analyze the receivedmetadata.

The body region (head, neck, chest, abdomen, pelvis, c spine, t spine, Ispine, sacrum, wrist, forearm, elbow, humerus, shoulder, clavicle,sternum, foot, ankle, tibia/fibia, knee, femur, hip, lower extremity,upper extremity, hand, facial, breast, procedure, scrotum, pet, fetal,total body, vascular, etc) and modifier (left, right, bilateral) aredetermined by processing the Study Description DICOM tag through analgorithm that uses positive keywords, negative keywords, regularexpressions, and keywords in relationship to spacing between words thatare defined for each Body Region in a database.

In one embodiment, the computer system analyzes the Study Descriptiontag specified by the DICOM protocol to determine the likely anatomicalarea represented by the study. How this tag is coded is not specified bythe standard and can be manufacturer or hospital specific. For example,some hospitals or clinics may code the tag based on the charge masterset up in the Hospital Information System (HIS) and is specific to eachinstitution. In one embodiment, the computer system 102 takes the textof the Study Description tag and compares it to a database of positiveand negative key words specified for each of the above-mentioned 33 bodyareas. For example, positive keywords for a head could include “head,cranium, skull, brain” while negative keywords for the head region couldinclude “neck, sinus, shoulder” etc. Each body region may have +/−100positive and negative keywords. The particular positive and negativekeywords stored in a database for each region can be selected based onexperience and testing.

The regular expressions are designed to determine both the presence ofpositive and negative keywords in the Study Description tag as well astheir location. For example, the keyword “CAP” in the Body Region Chest,Abdomen, and Pelvis body regions has a regular expression to determineif the text is at the beginning, on either side of punctuation, or withspaces on either side of the Study description tag. In the StudyDescription Tag “HEAD/C-SPINE/CAP” is more indicative of the Chest,Abdomen, Pelvis body regions since “CAP” appears to the right of a “/”whereas “SCAPULA COMP” would not match since the text “CAP” is not atthe beginning, on either side of punctuation, or has spaces on eitherside.

In one embodiment, the number of positive keyword hits compared to thenumber of negative keyword hits is compared for all the body regions.The result maybe something like Head (5 positive, 0 negative) Neck (3positive, 0 negative) Chest (5 positive, 1 negative) etc. Using thisexample, the exam would be classified as a Head and Neck and Chest wouldbe excluded.

The Study Description is processed through each Body Region's list ofpositive and negative key words to look for those relative key wordswhile utilizing regular expressions and word position and spaces todetermine a list of possible body regions. Those results of the negativekeyword comparison are used to exclude regions. The Body Regions withthe most positive keywords that have not been excluded using negativewords are chosen as the body regions of the imaging study.

Adjacent Body Regions are defined in a database cross table comprisingof the adjacent Body Regions. SubSpecialities are defined in a databasecross table for matches of the DICOM Tag Modality (MR, CT, US, DX, RG,CR, XR, MG, etc.) and the chosen Body Regions.

EXAMPLE 1

The study description ELBOW MIN 3 VWS-LT would be classified as an‘Elbow’ body region, left' modifier. If the modality was an ‘MR’ thesubspecialty would be ‘MSK’ but if the Modality was a ‘DX, CR, XR, RG’;the subspecialty would be ‘General’. The adjacent body region would be‘Forearm’ and ‘Humerus’.

EXAMPLE 2

The study description ‘CERVICAL SPINE’ would be classified as a ‘CSpine’ body region and no modifier. If the modality was an ‘MR’ or ‘CT’the subspecialty would be ‘MSK’ but if the Modality was a ‘DX, CR, XR,and RG’; the subspecialty would be ‘General’. The adjacent body regionwould be ‘NECK’, ‘CHEST’, ‘T SPINE’, ‘HEAD’, and ‘BREAST.’

In one embodiment, the disclosed technology selects the top two closestprior imaging studies for retrieval for comparison against a currentimaging study. In one embodiment, studies of adjacent anatomic regionsobtained with the same imaging modality are selected over images of thesame atomic region obtained with different imaging modalities. However,this may be user-selectable depending upon doctor preference. Particularanatomic regions that are adjacent to the anatomic region depicted inthe current imaging study are selected based on rules or heuristicsprogrammed into the computer system. Such heuristics may vary based onthe age of the patient. For example in infants, images that can beclassified as adjacent body parts may be different than those obtainedfrom adults. Alternatively, the heuristics or rules may vary based onthe sex of the patient.

As will be appreciated, the disclosed technology operates toautomatically retrieve prior imaging studies and reports that may beuseful by a physician or other medical provider in interpreting acurrent imaging study for the patient.

Although the embodiment of the disclosed technology is primarilydirected to the use of the technology for radiologists, it will beappreciated that the technology can also be used by other healthcareproviders such as dentists and pathology which use the DICOM standardfor imaging. In addition, the technology is not limited to the treatmentof humans. For example, the technology can also be applied to veterinaryimaging studies.

In one embodiment, the disclosed technology is implemented using asequence of stored program instructions that are executed by one or moreprocessors contained within the computer system 102. These processorsare typically programmed in any one of a number of well knownprogramming languages such as C#, C++, VB, JAVA, SQL. The followingpseudo-code listing illustrates one technique for the design andimplementation of a number of software modules that perform thefunctions described above. Details of how a database is programmed inthe computer system are set forth in detail in Appendix A.

Pseudo Code for Prior Imaging Study Retrieval System

Main Image Service

-   Receives Dicom Images on port 104 for the current studies to be    routed-   Updates the Properties Master Image Count-   Removes bad Dicom Tag 0x0009x0x1010-   Loops through active destination as defined in the    OutBoundDestination table in the ClientRouter SQL database that is    local to the router device.    -   For each destination a new folder is created using the        WorkingFolderPath as defined in the Properties table in the        ClientRouter database with a subfolder of Main and another        subfolder for each destination ID with a subfolder for each        Study Instance ID        -   Example D:\\ClientRouterDicom\Main\DestinationID\Study            InstanceID\    -   Each Dicom Images is written in to the corresponding        destination\Study Instance ID folder named by the        InstanceID+‘.dcm’    -   A Record is inserted in to the OutBoundQueue table in the        ClientRouter Database for each destination\Study Instance ID        combination    -   The Properties table is updated by the MainImage Size for each        file added    -   If these steps fail a Dicom Status Returns a status code of 1 to        the sending Dicom Device-   A Copy of any SR objects is achieved off to the    WorkingFolder\SR\StudyInstanceID\InstanceID.dcm folder    -   The SR object is parsed out and inserted in to the        ExamStructuredReport table-   A Unique entry is inserted in to the ClientRouter FacilityStation    table matching on CallingAE and IPAddress-   The Study Description is passed in to a method that uses the    keywords from the ClientRouter BodyRegion table to determine the    exam body region-   The Study Description is passed in to a method that uses the    keywords from the ClientRouter Modifier table to determine the exam    modifiers-   The StudyDescription, Modality, BodyRegionID, ModifierID, and    SubSpecialtyID is inserted in to the ClientRouter Exam table. The    SubSpecialtyID is determined by using a combination lookup table in    the ClientRouter SubSpecialityModalityBodyRegion table to match on    Modality and BodyRegion to get the SubSpeciatlityID. This table is    filled out via the Administrator tool.-   A record is inserted in to the ClientRouter PriorRequestQueue table-   A record is inserted in to the ClientRouterCentral Database    PriorRequestQueue table via the PriorRequestServiceClient webservice    which calls the ClientRouterCentral InsertPriorRequestQueue stored    procedure that inserts the request for each router set up in the    ClientRouterCentral PriorRequestRouters table by the original    routerID.-   A record is inserted in to the ClientRouter ExamDoseHistory table    for information-   A record is inserted in to the ClientRouter RecentStudyLog table and    kept for 4 hours to prevent this study from being fetched as a prior    if this patient has another study.

Main Image Forwarding Service

-   Next available record to process is fetched via the ClientRouter    LockOutBoundQueue Stored Procedure and is locked for processing.-   A new Thread is created to process the current record    -   Data is fetched from the OutBoundQueue table    -   The Last Write Time to the Record Folder Path is checked to see        if greater than 5 seconds. If yes, it will continue to process.        If No, the record is unlocked.    -   Images are examined to have any denied SOPClasses as defined in        the ClientRouter OutboundDestinations table in the        DeniedSOPClasses field. The images with denied SOP Classes are        moved to the WorkingFolder\BAD IMAGES\Study        InstanceID\SOPClass_InstanceID.dcm    -   A Dicom Assotiation is initiated with ea of the Destination(s)        and all of the remaining images are sent.    -   Upon each image confirmed sent; the image will be deleted from        the        WorkingFolder\Main\DestinationID\StudyInstanceID\InstanceID.dcm        folder.    -   The folder is checked if there are any files remaining and if        the file count=0 then the StudyInstanceID directory is deleted        and the OutBoundQueue Record is deleted    -   If files remain due to a failure; the OutboundQueue record is        unlocked for a retry later

Prior Scanner Service

-   Next available record to process is fetched via the ClientRouter    rad_LockPriorRequestQueue Stored Procedure and is locked for    processing from the PriorRequestQueue table.-   A new Thread is created to process the current record    -   Data is fetched from the PriorRequestQueue table    -   The Body Regions and Modifier are looked up in the ClientRouter        Exam table by Study Description and Modality    -   The Adjacent Body Regions and Modifiers are looked up in the        ClientRouter BodyRegionAdjacentRegions table    -   If the PriorRequestQueue isSearchByPatientID is true        -   The service does a dicom query back to the client PACS by            PatientID and generates a list of prior exams    -   If the PriorRequestQueue isSearchBy PatientID is false        -   The service does a dicom query back to the client PACS by            *PatientLastName* to pull all patients by the patient last            name        -   Those patients are filtered by the same birthdate and first            letter of the first name.        -   The service does another dicom query back to the PACS for            each of the filtered patients by their patientID and            generates a list of prior exams    -   The list of prior studies is sorted by exam date descending    -   The service passes the sorted list of prior studies to an        algorithm to auto fetch the top ‘X’ studies.        -   ‘X’ is determined by the original study body region and the            AutoFetchMax field in the BodyRegion table.        -   That value then sets the MaxFetchCount in PriorRequestQueue            table.        -   The algorithm loops through the prior studies to determine            the prior studies to automatically forward based on the            modality, modifier, body region, adjacent body regions using            the following criteria            -   First Pass to get all Exams where the modality matches                and is an exact body region match and modifiers match.            -   Second Pass to get all Exams where the modality matches                and is an adjacent body region and modifiers match.            -   Third Pass to get all Exams where the Body Region is a                match but different modalities and modifiers match.            -   Forth Pass to get all Exams where the Modalities are                different and the Body Region is Adjacent and modifiers                match.            -   Fifth Pass to get all Exams where the modality matches                and is an exact body region match            -   Sixth Pass to get all Exams where the modality matches                and is an adjacent body region.            -   Seventh Pass to get all Exams where the Body Region is a                match but different modalities.            -   Eighth Pass to get all Exams where the Modalities are                different and the Body Region is Adjacent.    -   The prior studies are inserted in to the PriorStudies table        -   If successful the PriorRequestQueue record is deleted        -   If the RequestedRouterID is set then the web service            DeletePriorRequestQueueItem is called to delete the request            in the ClientRouterCentral PriorRequestQueue table-   Another background thread processes the PriorStudies table    -   Each record is locked using the rad_LockPriorStudyToCentraIDB        stored procedure    -   The exam is inserted in to the RIS IAWorklistPriorExam table        calling the webservice InsertIAWorklistPriorExam    -   If successfully inserted;        -   The PriorStudies table is updated DateInsertedCentraIDB        -   If the record is set to autofetch (GetStudy field), the            record is inserted in to the PriorFetchQueue table-   Another background thread cleans up records using the stored    procedure rad_CleanUpPriorStudies every 5 seconds    -   In the PriorStudies table that are DateInsertedCentraIDB is not        null and DateInsertedCentraIDB is over 1 min old    -   In the PriorFetchQueue table where the GetStudy is true and the        DateCompleted is not null and the the GetReport is true and the        DateCompletedReport is not null

Prior Image Fetcher Service

-   Next available record to process is fetched via the ClientRouter    rad_LockPriorFetchStored Procedure and is locked for processing.-   A new Thread is created to process the current record    -   The webservice UpdateIAWorklistPriorExamsExamProgress updates        the IAWorklistPriorExam table that the study is inProcess    -   A dicom query checks the destination PACS if the StudyInstanceID        exists in the destination PACS    -   If True        -   The webservice UpdateIAWorklistPriorExamsExamProgress            updates the IAWorklistPriorExam table that the study is            inProcess=false, DateCompleted, DateLastAttempt,            CompleteTypeID, and LastError        -   The PriorFetchTable DateCompleted is updated    -   If False        -   A dicom move is issues from the source PACS to the            Destination PACS        -   If successful            -   The webservice UpdateIAWorklistPriorExamsExamProgress                updates the IAWorklistPriorExam table that the study is                inProcess=false, DateCompleted, DateLastAttempt,                CompleteTypeID, and LastError            -   The PriorFetchTable DateCompleted is updated        -   If failed            -   The webservice UpdateIAWorklistPriorExamsExamProgress                updates the IAWorklistPriorExam table that the study is                inProcess=false, DateLastAttempt, and LastError            -   The PriorFetchTable LastError, LastAttempt, inProcess is                updated-   Timer refreshes the destinations in case the destination is in    failover

Prior Image Server

-   Receives Dicom Images on port 105-   Updates the Properties Master Image Count-   Removes bad Dicom Tag 0x0009x0x1010-   Loops through active destination as defined in the    OutBoundDestination table in the ClientRouter SQL database that is    local to the router device.    -   For each destination a new folder is created using the        WorkingFolderPath as defined in the Properties table in the        ClientRouter database with a subfolder of Main and another        subfolder for each destination ID with a subfolder for each        Study Instance ID        -   Example D:\AClientRouterDicom\Priors\1\Study InstanceID\    -   Each Dicom Images is written in to the corresponding        destination\Study Instance ID folder named by the        InstanceID+‘.dcm’    -   A Record is inserted in to the OutBoundQueue table in the        ClientRouter Database for each destination\Study Instance ID        combination    -   The Properties table is updated by the MainImage Size for each        file added    -   If these steps fail a Dicom Status Returns a status code of 1 to        the sending Dicom Device-   A Copy of any SR objects is achieved off to the    WorkingFolder\SR\StudyInstanceID\InstanceID.dcm folder    -   The SR object is parsed out and inserted in to the        ExamStructuredReport table-   A Unique entry is inserted in to the ClientRouter FacilityStation    table matching on CallingAE and IPAddress-   The Study Description is passed in to a method that uses the    keywords from the ClientRouter BodyRegion table to determine the    exam body region-   The Study Description is passed in to a method that uses the    keywords from the ClientRouter Modifier table to determine the exam    modifiers-   The StudyDescription, Modality, BodyRegionID, ModifierID, and    SubSpecialtyID is inserted in to the ClientRouter Exam table. The    SubSpecialtyID is determined by using a combination lookup table in    the ClientRouter SubSpecialityModalityBodyRegion table to match on    Modality and BodyRegion to get the SubSpeciatlityID. This table is    filled out via the Administrator tool.-   A record is inserted in to the ClientRouter RecentStudyLog table and    kept for 4 hours to prevent this study from being fetched as a prior    if this patient has another study.

Prior Image Forwarder Service

-   Next available record to process is fetched via the ClientRouter    rad_LockPriorImageQueue Stored Procedure and is locked for    processing.-   A new Thread is created to process the current record    -   Data is fetched from the PriorImageQueue table    -   The Last Write Time to the Record Folder Path is checked to see        if greater than 5 seconds. If yes, it will continue to process.        If No, the record is unlocked.    -   Images are examined to have any denied SOPClasses as defined in        the ClientRouter OutboundDestinations table in the        DeniedSOPClasses field. The images with denied SOP Classes are        moved to the WorkingFolder\BAD IMAGES\Study        InstanceID\SOPCIass_InstanceID.dcm    -   A Dicom Assotiation is initiated with ea of the Destination(s)        and all of the remaining images are sent.    -   Upon each image confirmed sent; the image will be deleted from        the        WorkingFolder\Priors\DestinationID\StudyInstanceID\InstanceID.dcm        folder.    -   The folder is checked if there are any files remaining and if        the file count=0 then the StudyInstanceID directory is deleted        and the PriorImageQueue Record is deleted    -   If files remain due to a failure; the PriorImageQueue record is        unlocked for a retry later

MonitorCentralPriorStudiesService:

-   Every second the service calls the webservice    GetIAWorklistPriorExamsToProcess for the individual router ID and    returns a collection of exam objects. The    GetIAWorklistPriorExamsToProcess calls the RIS database    GetIAWorklistPriorExamsToProcess Stored Procedure to fetch all data    from the IAWorklistPriorExams table where the routerID matches and    the GetStudy=true and InProcess=false and DateStarted is null-   If the collection count is greater than 0 the exams are inserted in    to the ClientRouter rad_InsertPriorStudiesManualRequest which    inserts the exams in to the PriorFetchQueue table

Monitor CentralPriorRequests

-   Every second the service calls the webservice GetPriorRequests by    that routerID. The GetPriorRequests call the ClientRouterCentral    database GetPriorRequestQueue stored procedure that gets the top 100    records from the ClientRouterCentral PriorRequestQueue table where    the RequstedRouterID matches and the DateRouterDownloaded is null-   If the collection count is greater than 0 the exams are inserted in    to the ClientRouter rad_InsertPriorRequestQueue which inserts the    exams in to the PriorRequestQueue Table

Prior Report Fetcher Service

-   Next available record to process is fetched via the ClientRouter    rad_LockPriorReportFetchStored Procedure and is locked for    processing for all prior exams requested.-   A new Thread is created to process the current record    -   Data is fetched from the ClientRouter.PriorFetchQueue table for        the record.    -   The webservice UpdateIAWorklistPriorExamsReportProgress is        called to update the progress on the central        RIS.IAWorklistPriorExams table    -   The ReportSystemTypeID is determined from the        ClientRouter.Facility table which assigns a facilityID but the        unique IPAddress/AE Title combination.    -   Depending on the ReportSystemTypeID (EPIC, GE RIS/IC, MEDITECH),        the prior report, dictated by, and dictated date are returned.    -   The report is formatted to monospace text    -   The report, dictated by, dictated date are updated in the        RIS.IAWorklistPriorExam table via the webservice        UpdateIAWorklistPriorExamReport.

Embodiments of the subject matter and the operations described in thisspecification can be implemented in digital electronic circuitry, or incomputer software, firmware, or hardware, including the structuresdisclosed in this specification and their structural equivalents, or incombinations of one or more of them. Embodiments of the subject matterdescribed in this specification can be implemented as one or morecomputer programs, i.e., one or more modules of computer programinstructions, encoded on computer storage medium for execution by, or tocontrol the operation of, data processing apparatus.

A computer storage medium can be, or can be included in, acomputer-readable non-transitory storage device, a computer-readablestorage substrate, a random or serial access memory array or device, ora combination of one or more of them. Moreover, while a computer storagemedium is not a propagated signal, a computer storage medium can be asource or destination of computer program instructions encoded in anartificially-generated propagated signal. The computer storage mediumalso can be, or can be included in, one or more separate physicalcomponents or media (e.g., multiple CDs, disks, or other storagedevices). The operations described in this specification can beimplemented as operations performed by a data processing apparatus ondata stored on one or more computer-readable storage devices or receivedfrom other sources.

The term “programmed processor” encompasses all kinds of apparatus,devices, and machines for processing data, including by way of example aprogrammable processor, a computer, a system on a chip, or multipleones, or combinations, of the foregoing. The apparatus can includespecial purpose logic circuitry, e.g., an FPGA (field programmable gatearray) or an ASIC (application-specific integrated circuit). Theapparatus also can include, in addition to hardware, code that createsan execution environment for the computer program in question, e.g.,code that constitutes processor firmware, a protocol stack, a databasemanagement system, an operating system, a cross-platform runtimeenvironment, a virtual machine, or a combination of one or more of them.The apparatus and execution environment can realize various differentcomputing model infrastructures, such as web services, distributedcomputing and grid computing infrastructures.

A computer program (also known as a program, software, softwareapplication, script, or code) can be written in any form of programminglanguage, including compiled or interpreted languages, declarative orprocedural languages, and it can be deployed in any form, including as astand-alone program or as a module, component, subroutine, object, orother unit suitable for use in a computing environment. A computerprogram may, but need not, correspond to a file in a file system. Aprogram can be stored in a portion of a file that holds other programsor data (e.g., one or more scripts stored in a markup languagedocument), in a single file dedicated to the program in question, or inmultiple coordinated files (e.g., files that store one or more modules,sub-programs, or portions of code). A computer program can be deployedto be executed on one computer or on multiple computers that are locatedat one site or distributed across multiple sites and interconnected by acommunication network.

The processes and logic flows described in this specification can beperformed by one or more programmable processors executing one or morecomputer programs to perform actions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, e.g., an FPGA (field programmable gate array) or an ASIC(application-specific integrated circuit).

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computer. Generally, aprocessor will receive instructions and data from a read-only memory ora random access memory or both. The essential elements of a computer area processor for performing actions in accordance with instructions andone or more memory devices for storing instructions and data. Generally,a computer will also include, or be operatively coupled to receive datafrom or transfer data to, or both, one or more mass storage devices forstoring data, e.g., magnetic, magneto-optical disks, or optical disks.Devices suitable for storing computer program instructions and datainclude all forms of non-volatile memory, media and memory devices,including by way of example semiconductor memory devices, e.g., EPROM,EEPROM, and flash memory devices; magnetic disks, e.g., internal harddisks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROMdisks. The processor and the memory can be supplemented by, orincorporated in, special purpose logic circuitry.

To provide for interaction with a user, embodiments of the subjectmatter described in this specification can be implemented on a computerhaving a display device, e.g., an LCD (liquid crystal display), LED(light emitting diode), or OLED (organic light emitting diode) monitor,for displaying information to the user and a keyboard and a pointingdevice, e.g., a mouse or a trackball, by which the user can provideinput to the computer. In some implementations, a touch screen can beused to display information and to receive input from a user. Otherkinds of devices can be used to provide for interaction with a user aswell; for example, feedback provided to the user can be any form ofsensory feedback, e.g., visual feedback, auditory feedback, or tactilefeedback; and input from the user can be received in any form, includingacoustic, speech, or tactile input. In addition, a computer can interactwith a user by sending documents to and receiving documents from adevice that is used by the user; for example, by sending web pages to aweb browser on a user's client device in response to requests receivedfrom the web browser.

Embodiments of the subject matter described in this specification can beimplemented in a computing system that includes a back-end component,e.g., as a data server, or that includes a middleware component, e.g.,an application server, or that includes a front-end component, e.g., aclient computer having a graphical user interface or a Web browserthrough which a user can interact with an implementation of the subjectmatter described in this specification, or any combination of one ormore such back-end, middleware, or front-end components. The componentsof the system can be interconnected by any form or medium of digitaldata communication, e.g., a communication network. Examples ofcommunication networks include a local area network (“LAN”) and a widearea network (“WAN”), an inter-network (e.g., the Internet), andpeer-to-peer networks (e.g., ad hoc peer-to-peer networks).

The computing system can include any number of clients and servers. Aclient and server are generally remote from each other and typicallyinteract through a communication network. The relationship of client andserver arises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other. In someembodiments, a server transmits data (e.g., an HTML page) to a clientdevice (e.g., for purposes of displaying data to and receiving userinput from a user interacting with the client device). Data generated atthe client device (e.g., a result of the user interaction) can bereceived from the client device at the server.

From the foregoing, it will be appreciated that specific embodiments ofthe invention have been described herein for purposes of illustration,but that various modifications may be made without deviating from thespirit and scope of the invention. Accordingly, the invention is notlimited except as by the appended claims.

I/We claim:
 1. A computer system for retrieving imaging studies of apatient, comprising: a memory that stores a sequence of programinstructions; a processor configured to execute the instructions inorder to: receive an imaging study of a patient; analyze metadataassociated with the received imaging study to identify the patient andto identify an anatomic region depicted in the imaging study; requestmetadata for prior imaging studies performed on the patient; analyze themetadata to identify at least one prior imaging study that is relevantto the received imaging study; request images and associated reports forthe at least one prior relevant imaging study.
 2. The computer system ofclaim 1, wherein the processor is configured to execute instructionsthat cause the processor to identify the relevant prior imaging studybased on heuristics applied to the metadata for the prior imagingstudies.
 3. The computer system of claim 1, wherein the processor isconfigured to analyze a DICOM study description tag contained in themetadata of a prior imaging study against a number of positive andnegative keywords representing different anatomic regions to identifyrelevant prior imaging studies.
 4. A non-transitory computer readablemedia having instructions stored thereon that are executable by aprocessor to retrieve prior imaging studies of a patient, by: receivingan imaging study of a patient; analyzing metadata associated with thereceived imaging study to identify the patient and to identify ananatomic region depicted in the imaging study; requesting metadata forprior imaging studies performed on the patient; analyzing the metadatato identify at least one prior imaging study that is relevant to thereceived imaging study. request images and associated reports for the atleast one prior relevant imaging study.